home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000177_owner-urn-ietf _Fri Nov 15 15:33:05 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17324 for urn-ietf-out; Fri, 15 Nov 1996 15:33:05 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17319 for <urn-ietf@services.bunyip.com>; Fri, 15 Nov 1996 15:33:03 -0500
  3. Received: from ns.alis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA00667  (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 15:32:57 -0500
  5. Received: from fyergeau.alis.com ([207.81.28.17]) by genstar.alis.ca (8.7.5/8.7.3) with SMTP id PAA28227; Fri, 15 Nov 1996 15:32:27 -0500 (EST)
  6. Message-Id: <2.2.32.19961115202810.0071e124@genstar.alis.ca>
  7. X-Sender: yergeau@genstar.alis.ca
  8. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="iso-8859-1"
  11. Date: Fri, 15 Nov 1996 15:28:10 -0500
  12. To: Ron Daniel <rdaniel@acl.lanl.gov>
  13. From: Francois Yergeau <yergeau@alis.com>
  14. Subject: Re: [URN] Re: I18N does not belong in URNs
  15. Cc: urn-ietf@bunyip.com
  16. Content-Transfer-Encoding: quoted-printable
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: Francois Yergeau <yergeau@alis.com>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. =C0 09:27 15-11-96 -0700, Ron Daniel a =E9crit :
  23. >A couple of points here. First, the URI RFC (1630) says that 8-bit
  24. >values should be %encoded.
  25.  
  26. RFC 1630 is informational, and clearly does not address internationalizat=
  27. ion
  28. issues. This has plagued URLs for a long time, as 8-bit octets have no
  29. defined meaning.
  30.  
  31. >Not all of the transports through which
  32. >URNs will be sent are 8-bit. An unfortunate fact of life.
  33.  
  34. True, but of limited relevance.  I'm not calling for forbidding %-encodin=
  35. g,
  36. only for not making it compulsory and burden the whole world *forever* wi=
  37. th
  38. the present-day limitations of basically one Internet "transport" (mail).
  39. If you need to mail an UTF-8 URN, please go ahead and %-encode it, or use
  40. one of the MIME encodings that were designed exactly for that.
  41.  
  42. >Second, Ryan's "URN Syntax" draft essentially says that, as an optimizat=
  43. ion,
  44. >if a sender and reciever know that they are using an 8-bit clean transpo=
  45. rt,
  46. >then they could sent UTF-8 as octets instead of %HH. This optimization
  47. >may become commonly used, but for compatability with existing software
  48. >we are much safer saying that the standard is %encoded.
  49.  
  50. This should be exactly the other way around: if you are afraid of a 7-bit
  51. transport, then you MAY %-encode everything.
  52.  
  53. >Making %encoding the standard seems (to me at least) to be perfectly
  54. >in line with the homily about being conservative in what you send.
  55.  
  56. The homily is about sending *exactly* what the spec says, not about makin=
  57. g
  58. the spec overly conservative and precluding progress.  Moreover, "Be
  59. conservative in what you send" would mean that with %HH the standard, 8-b=
  60. it
  61. would be effectively forbidden even with 8-bit transports, contradicting =
  62. the
  63. paragraph above.  A useless layer of encoding, plus bandwidth and storage
  64. waste forever.  Not sound design IMHO, there are better ways to deal with
  65. the occasional 7-bit transport than to mandate 7 bits everywhere for all
  66. times; providing a way out for those cases is sufficient.
  67.  
  68. Regards,
  69.  
  70. --=20
  71. Fran=E7ois Yergeau <yergeau@alis.com>
  72. Alis Technologies Inc., Montr=E9al
  73. T=E9l : +1 (514) 747-2547
  74. Fax : +1 (514) 747-2561
  75.